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Abstract — In this work, we develop a computational framework 
for fully automatic deployment of a team of unicycles from a 
global specification given as an LTL formula over some regions 
of interest. Our hierarchical approach consists of four steps: (i) 
the construction of finite abstractions for the motions of each 
robot, (ii) the parallel composition of the abstractions, (iii) the 
generation of a satisfying motion of the team; (iv) mapping this 
motion to individual robot control and communication strategies. 
The main result of the paper is an algorithm to reduce the 
amount of inter-robot communication during the fourth step of 
the procedure. 

L INTRODUCTION 

Motion planning and control is a fundamental problem that 
have been extensively studied in the robotics literature [ ]. 
Most of the existing works have focused on point-to-point 
navigation, where a mobile robot is required to travel from 
an initial to a final point or region, while avoiding obstacles. 
Several solutions have been proposed for this problem, in- 
cluding cell decomposition based approaches that use graph 
search algorithms such as A* [ ], [ ], continuous approaches 
involving navigation functions and potential fields [ ], and 
sampling-based methods such as Rapidly-Exploring Random 
Trees (RRTs) [],[]. However, the above approaches can- 
not accommodate complex task specifications, where a robot 
might be required to satisfy some temporal and logic con- 
straints, e.g., "avoid E for all times; visit A or B and then be 
at either C or D for all times". 

In recent years, there has been an increased interest in using 
temporal logics to specify mission plans for robots [ ]-[ ]. 
Temporal logics [ ]-[.^] are appealing because they provide 
formal, rich, and high level languages in which to describe 
complex missions. For example, the above task specification 
translates immediately to the Linear Temporal Logic (LTL) 
formula B^E A<}{{AV B) A<}B{CV D)), where ^, V, A are 
the usual Boolean operators, and 0, D are two temporal 
operators standing for "eventually" and "always", respectively. 
Computation Tree Logic (CTL) and /i -calculus have also been 
advocated as robot motion specification languages [ ], [ ]. 
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To use formal languages and model checking techniques for 
robot motion planning and control, a fundamental challenge 
is to construct finite models that accurately capture the robot 
motion and control capabilities. Most current approaches are 
based on the notion of abstraction [ ]. Enabled by recent 
developments in hierarchical abstractions of dynamical sys- 
tems [ ]-[ ]), it is now possible to model the motions 
of several types of robots as finite transition systems over 
a cell-based decomposition of the environment. By using 
equivalence relations such as simulations and bisimulations 
[ ], the motion planning and control problem can be reduced 
to a model checking or formal synthesis problem for a finite 
transition system, for which several techniques are readily 
available [ ], [ ]-[25]. 

Some recent works suggest that such single-robot tech- 
niques can be extended to multi-robot systems through the 
use of parallel composition (synchronous products) [ ], [26]. 
The main advantage of such a bottom-up approach is that 
the motion planning problem can be solved by off-the-shelf 
model checking on the parallel composition followed by 
canonical projection on the individual transition systems. The 
two main limitations, both caused by the parallel composition, 
are the state space explosion problem and the need for inter- 
robot synchronization (communication) every time a robot 
leaves its current region. In our previous work, we proposed 
bisimulation-type techniques to reduce the size of the syn- 
chronous product in the case when the robots are identical [27] 
and derived classes of specifications that do not require any 
inter-robot communication [ ]. By drawing inspiration from 
distributed formal synthesis [ ], we have also proposed top- 
down approaches that do not require the parallel composition 
of the individual transition systems [ ]. While cheaper, this 
method restricts the specifications to regular expressions. 

In this paper, we focus on bottom-up approaches based on 
parallel composition and address one of the limitations men- 
tioned above. Specifically, we develop an algorithm that deter- 
mines a reduced number of synchronization (communication) 
moments along a satisfying run of the parallel composition. 
Our approach is heuristic - we do not minimize the necessary 
amount of communication. However, our approach can be 
directly modified to produce minimal sets of synchronization 
moments. Our extensive experiments show that the proposed 
algorithm leads to a significant reduction in the number of 
synchronizations. We integrate this algorithm into a software 
tool for automatic deployment of unicycles with polyhedral 
control constraints from specifications given as LTL formulas 



over the regions of an environment with a polyhedral partition. 
The user friendly tool, which is freely downloadable from http: 
//hyness.bu.edu/^software/MRRC.htm, takes as input a user- 
defined environment, an LTL formula over some poly topes, the 
number of unicycles, and their forward and angular velocity 
constraints. It returns a control and communication strategy 
for each robot in the team. While transparent to the user, the 
tool also implements triangulation and polyhedral operation 
algorithms from [ ], [ ], [ ], LTL to Biichi conversion [ ], 
and robot abstraction by combining the affine vector field 
computation from [ ] with input-output regulation [ ]. 

The remainder of the paper is organized as follows. Sec. 
Ilpresents some preliminary notions necessary throughout the 
paper. Sec. Ill formulates the general problem we want to 
solve, outlines the solution and then presents a specific prob- 
lem of interest. The main contribution of the paper is given 
in Sec. IV. To illustrate the method and the main concepts, a 
case study is examined throughout the paper and concluded 
in Sec. V, while an additional case study is included in Sec. 
VI. The paper ends with conclusions and final remarks in Sec. 
VII. 

II. PRELIMINARIES 

Definition 2.1: A deterministic finite transition system is a 
tuple T = (2,^0, ^7 n,p), where 2 is a (finite) set of states, 
^0 ^ G is the initial state, g x 2 is a transition relation, 
n is a finite set of atomic propositions (observations), and 
p : 2 ^ 2^ is the observation map. 

To avoid supplementary notations, we do not include control 
inputs in Definition 2.1 since T is deterministic, i.e. we can 
choose any available transition at a given state. A trajectory 
or run of T starting from q is an infinite sequence r = 
r(l)r(2)r(3) . . . with the property that r{l) = qo, r{i) G 2, and 
(r(/),r(/+ 1)) G^, V/> 1. A trajectory r = r(l)r(2)r(3) . . . 
defines an infinite word over set 2^, w = w(l)w(2)w(3) . . ., 
where w{i) = p(r(/)). With a slight abuse of notation, we will 
denote by p(r) the word generated by run r. The set of all 
words that can be generated by T is called the (CO-) language 
of T. 

In this paper we consider motion specifications given as 
formulas of Linear Temporal Logic (LTL) [ ]. A formal 
definition for the syntax and semantics of LTL formulas is 
beyond the scope of this paper. Informally, the LTL formulas 
are recursively defined over a set of atomic propositions 11, 
by using the standard boolean operators and a set of temporal 
operators. The boolean operators are (negations), V (disjunc- 
tion), A (conjunction), and the temporal operators that we use 
are: U (standing for "until"), □ ("always"), ("eventually"). 
LTL formulas are interpreted over infinite words over set 
2^, as are those generated by transition system T. For LTL 
formulas satisfied by continuous systems, we restrict the class 
of specifications to LTL_x, which are LTL formulas without 
the "next" temporal operator. We note that, the class of LTL_x 
is not at all restrictive, since for continuous systems LTL_x 
captures the full expressivity power of LTL [8]. 



All LTL formulas can be converted into a generalized Biichi 
automaton [ ] defined below: 

Definition 2.2 (Generalized Biichi automaton): A gen- 
eralized Biichi automaton is a tuple ^ = {S^sq^IL^^^^F), 
where 

• 5" is a finite set of states, 

• So CS is the set of initial states, 

• L is the input alphabet, 

• -^^^ S xlLx S is 3. (nondeterministic) transition relation, 

• F C 2*^ is the set of sets of accepting (final) states. 

The semantics of a Biichi automaton is defined over infinite 
input words over Z. An input word is accepted by automaton 
^ if and only if there exists a run produced by that word 
with the property that all sets from F are infinitely often 
visited. Due to the complicated acceptance condition (multiple 
sets have to be infinitely often visited), a generalized Biichi 
automaton is usually converted into a regular (degeneralized) 
Biichi automaton. A regular Biichi automaton has only one set 
of final states, i.e. F e2^. Any generalized Biichi automaton 
can be transformed into a regular Biichi automaton that accepts 
the exact same words. A conversion algorithm can be found 
in [32]. 

For any LTL formula (j) over a set of atomic propositions 
n, there exists a (generalized or regular) Biichi automaton 
^0 with input alphabet L C 2^ accepting all and only infinite 
words over 11 satisfying formula (j) [ ]. 

Given a transition system T with set of observations 11 and 
an LTL formula (j) over 11, one can find a trajectory of T which 
generates a word satisfying (j). This can be done by using 
model checking inspired tools [ ], which begin by translating 
to a regular Biichi automaton Then, the product of T 
with is computed, operation that can be informally viewed 
as a matching between observations of T and transitions 
of An accepted run (if any) of the obtained product 
automaton is chosen. This accepted run is projected into a 
run r of r, which generates a word satisfying (j). Although r 
is infinite, it has a finite-representable form, namely it consists 
of a finite string called prefix, followed by infinite repetitions 
of another finite string called suffix (such a run is said to be 
in the prefix-suffix form). A cost criterion can be imposed 
on the obtained run r, e.g. the minimum memory for storing 
it, or a minimum cost on transitions of T encountered when 
following the prefix and a finite number of repetitions of the 
suffix. The run r can be be directly generated on T if one can 
deterministically control (impose) the transition that appears in 
each state (which is true for a deterministic transition system 
T defined in 2.1). 

III. PROBLEM FORMULATION AND APPROACH 

In this paper we are interested in developing an automated 
framework for deploying identical unicycle robots in planar 
environments. Assume that such a robot is described by 
(x^y^G), where (x,j) G M? gives the position vector of the 
robot's center of rotation, and 6 is its orientation. The control 
w = [v^co]^ e W C consists of forward driving (v) and 
steering (co) speeds, where W is a set capturing control bounds. 



We assume that W includes an open ball around the origin, 
which implies that v can be also negative (i.e. the robot can 
drive backwards). The kinematics of the unicycle are given 
by: 

I x = vcosO 

< y = vsinO (1) 

[ e = co 

Assume that some robots move in a polygonal convex 
environment with kinematics given by (1), where a set H of 
non-overlapping convex polygonal regions^ are defined. The 
general deployment problem for a team of unicycle robots 
satisfying an LTL formula is given by: 

Problem 3.1: Given a team of n unicycles and a task in the 
form of an LTL_x formula (j) over a set of regions of interest 
n, design individual communication and control strategies for 
the mobile robots such that the motion of the team satisfies 
the specification. 

We assume that the unicycles are identical and have a small 
(negligible) size when compared to the size of the environment 
and of the predefined regions. Moreover, we consider that a 
unicycle visits (or avoids) a region when a specific reference 
point on it visits (or avoids) that region. To fully understand 
Problem 3.1, we say that the motion of the team satisfies 
an LTL formula (j) if the word generated during the motion 
satisfies (j). The word generated by a set of n continuous 
trajectories is a straightforward generalization of the definition 
of the word generated by a single trajectory [ ]. Informally, the 
word generated by the team motion consists of a sequence of 
elements of 2^ containing the satisfied propositions (visited 
regions) as time evolves. In a generated word, there are no 
finite successive repetition of the same element of 2^, and 
infinite successive repetitions of the same element appear if 
and only if each robot trajectory stays inside a region. 

Case study: For better understanding of introduced con- 
cepts, throughout this paper, we consider a case study with 
the environment illustrated by Fig. 1, where 3 unicycle-type 
mobile robots evolve. The reference point of each unicycle 
is its "nose", the center of rotation is the middle of the rear 
axis, and the initial deployment of robots is the one from Fig. 
L The imposed specification requires that "regions TTi and 
7l4 and 71^ are simultaneously visited, and regions 7l2 and Tls 
are simultaneously visited, infinitely often, while region 713 is 
always avoided". This specification translates to the following 
LTL formula: 

(j) = □^;r3 AnO((;ri A:/r4 A:/r6) A0(;r2 A:/r5)) (2) 

■ 

To provide a deployment strategy for Problem 3.1, we will 
first combine various techniques from computational geom- 
etry, motion planning and model checking until we obtain a 
solution in the form of a sequence of tuples of smaller regions 
and feedback control laws in each of these regions. After this, 

^Note that convex non-polygonal regions can be bounded by convex 
polygonal regions with arbitrary accuracy, and non-convex regions can be 
divided into adjacent convex regions 




Fig. 1. A polygonal environment, six regions of interest, and the initial 
deployment of three unicycle robots. Robot 1 is green, robot 2 is blue, and 
robot 3 is red; there is no relation between the robot and the region colors. 
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Fig. 2. Triangular partition consisting of 40 regions, corresponding to the 
environment from Fig. 1. 

we focus on the main contribution of the paper, namely finding 
a reduced set of communication (synchronization) moments 
among robots, while still guaranteeing the satisfaction of the 
specification. The main steps of the algorithmic approach for 
solving Problem 3.1 are given in the following 3 subsections. 

A. Robot Abstraction 

We first abstract the motion capabilities of each robot to a 
finite transition system. To this end, the environment is first 
partitioned into convex regions (cells) such that two adjacent 
cells exactly share a facet, and each region from 11 consists 
of a set of adjacent cells. Such a partition can be constructed 
by employing cell decomposition algorithms used in motion 
planning and computational geometry, e.g. one can use a 
constraint triangulation [ ] or a polytopal partition [ ] . Let us 
denote the set of partition elements by C = {ci,C2, . . . 
For a clear understanding. Fig. 2 presents a triangular partition 
obtained for the environment from Fig. 1. We use a triangular 
partition for the case study presented throughout this paper, 
although our approach can be applied to any partition scheme. 

The second step is to reduce each unicycle with kinematics 
(1) to a fully-actuated point robot placed in unicycle's ref- 
erence point. We use the approach from [ ], where a non- 
singular map relates the velocity u of the reference point to the 



initial controls w = [v, co]^. Note that u can be conservatively 
bounded by a polyhedral set U, such that the resulted control 
w is in W. 

Definition 3.1: The transition system abstracting the mo- 
tion capabilities of unicycle /, / = 1 , . . . , ^ has the form 
Ti = {Qi,qoi,^i,nu{(d},p), where: 

• Qi = C, i.e. the set of states is given by the cells from 
partition; 

• The initial state qot G C is the cell where the reference 
point of unicycle / is initially deployed; 

• The transition relation C x C is created as follows: 

- {ci^Ci) if we can design a feedback control 
law making cell c/ invariant with respect to the 
trajectories of the reference point of unicycle /, and 

- {ci^Cj) G^i, / 7^ j if Ci and cj are adjacent and we can 
design a feedback control law such that the reference 
point of unicycle / leaves cell Ci in finite time, by 
crossing the common facet of Ci and cj', 

• n labels the set of regions of interest, and symbol 
corresponds to the space not covered by any region of 
interest; 

• The observation map p associates each cell from the 
partition with the corresponding proposition from n, or 
with the symbol 0. 

Considering the unicycles reduced to their reference point, 
the construction of the continuous controllers corresponding 
to the transition relation from Definition 3.1 is done by using 
results for facet reachability and invariance in polytopes [ ]. 
We just mention that designing such feedback control laws 
reduces to solving a set of linear programming problems in 
every cell from partition, where the constraints result from the 
control bounds U and the considered adjacent cells. Also, since 
the reference point is fully-actuated and the control bounds 
U include the origin, we obtain a transition between every 
adjacent cells, as well as a self-loop in every state of Tf. 
Therefore, a run of Ti can be implemented by unicycle / by 
imposing specific control laws for the reference point in the 
visited cells, and by mapping these controls to w. We note that, 
since the unicycles are identical, the only difference between 
transition systems Tf is given by their initial states. 

Case study revisited: The partition from Fig. 2 enables us 
to construct a transition system with 40 states corresponding 
to each robot, where the transitions are based on adjacency 
relation between cells from environment, and the observations 
are given by the satisfied region. Fig. 3 illustrates some vector 
fields obtained from driving-to-facet control problems and 
from invariance controlled design, as well as the corresponding 
transitions from system Ti. ■ 

B. Satisfying Behavior of the Team 

In this part of the solution, we use ideas from [26], [27] to 
find a run (for the whole team) satisfying the formula (j). The 
n transition systems Tf are combined into a global one, 7g, 
capturing the synchronized motion of the team (synchronized 
in the sense that robots change at the same time the occupied 




Fig. 3. Left: vector fields driving any initial state from cell cg to a neighbor 
(blue and red colors), and vector field making invariant (black). Right: 
transitions from Ti are colored in accordance with the colors of the created 
vector fields. Observation given by map p is placed near each state. 



cells from partition, or states from 7]). Then, by using model 
checking inspired techniques as mentioned in Sec. II, we find a 
run for the whole team, in the form of a prefix-suffix sequence 
of tuples. 

Definition 3.2: The transition system Tg = {Qgj^go^^g 
jUjPg) capturing the behavior of the group of n robots is 
defined as the synchronous product of all 7^'s, / = 1, . . . 

• Gg = 2i X ... X 2^, 

• ^GO = (^01, •••,^0^), 

• Qg X Qg is defined by 

{{qi,...,qn),{q[,...,q'ri)) if and only if 

{qi,q-) e^i, i= 1,...,^, 

• n is the observation set, 

• Pg : Gg ^ 2^ is defined by pG ((^i, . . . = 

uLilPte)}. 

We now find a run R of Tg such that the generated word 
Pg{R) satisfies (j). For this, we use the tool from [ ], and we 
impose the optimality criterion that during the prefix and one 
iteration of the suffix, the total number of movements between 
partition cells is minimized. This is accomplished by adding 
weights to transitions of Tg, where the weight of a transition 
equals the number of robots that change their state from Tf. 
These weight are inherited when taking the product of Tg with 
B(j). This optimality criterion minimizes the memory used on 
robots for storing motion controllers (feedback control laws 
driving robots from one cell to an adjacent one). 

In [26], [27], such a global run was projected to individual 
runs of robots. Then, the robots can be controlled by the affine 
feedback controllers that map to unicycle controls from Sec. 
Ill- A. In deployment, when the team makes a transition from 
one tuple of the run to the next, the robots must synchronize 
(communicate) with each other and wait until every member 
finishes the previous transition. The synchronization will occur 
on the boundaries of the cells when crossing from a cell to 
another. 

Remark 3.1: Since the robots are identical, the number 
of states from Tg can be reduced by designing a bisimilar 
(equivalent) transition system (the quotient induced by robot 
permutations) [ ]. Thus, the computation complexity of find- 
ing a run R is manageable even for large teams. 



Case study revisited: For the above introduced example 
(Fig. 1 and 2, and specification (2)), we obtain a team run 
R = prefix, suffix, suffix, . . ., with 7 states in prefix and 8 states 
in suffix, as shown in Eqn. (3). 



prefix : 



suffix : 




(3) 



Run R means that the robots start from their initial cells, 
and the first to robots evolve to cells C2 and C3 respectively. 
The synchronization imposed by the construction of Tg and 
used in [ ], [ ] would require that the first two robots cross 
from C7 to C2 and from C4 to C3 synchronously (at exactly the 
same time), and so on. By construction, the word generated 
by R over the set of propositions n, Pg(^), satisfies formula (j) 
from Eqn. (2). However, the mentioned synchronizations are 
disadvantageous, because they require a lot of communication 
and waiting, and they imply many discontinuities is the control 
input of each robot (due to the frequent stops at the facets of 
traversed cell). Intuitively, one can observe that synchroniza- 
tions along prefix of R for example do not contribute to the 
satisfaction of the formula, nor they would lead to its violation, 
because the robots just head towards some regions they have 
to visit. ■ 

As evident from the case study, deployment strategies for a 
satisfying run R as proposed in [26], [27] require a significant 
amount of synchronization (and thus communication) among 
the team. In this paper, rather than synchronizing robots for 
each transition in R, we aim in finding a reduced set of 
transitions along R that require synchronization. This problem 
is formalized in Sec. III-C. Its solution is given in Sec. 
IV, in the form of an algorithmic procedure returning a 
reduced number of necessary synchronization moments along 
R, together with deployment strategies for robots. We note 
that in [26], we developed an algorithmic tool that tests if 
unsynchronized motion of the team can lead to a violation 
of the formula. If the answer is yes (such is the case for 
the case study considered in this paper), then synchronization 
required in [ ] cannot be reduced. Therefore, the solution to 
the problem formulated in Sec. III-C constitutes a significant 
improvement over [26]. 

C. Minimizing Communication 

Problem 3.2: Given a run R of Tg that satisfies the LTL 
specification 0, find a team control and communication strat- 
egy that requires a reduced number of inter-robot synchroniza- 
tions than in the synchronization-based deployment, while at 



the same time guaranteeing that the produced motion of the 
team satisfies (j). 

Central to our approach to Problem 3.2 is an algorithm 
that takes as input the satisfying run R = R{l)R{2)R{3) . . . 
and returns a reduced number of necessary synchronization 
moments, where the moment along R is defined as the 
index / corresponding to R{i). Motivated by the fact that 
synchronization by stopping and waiting at region boundaries 
is not always necessary to produce a desired tuple, we consider 
two types of synchronizations: in a weak synchronization, 
a certain tuple is generated because there exists an instant 
of time at which the robots are in the corresponding cells; 
a strong synchronization ensures that a sequence of two 
successive tuples from R is observed. Note that a strong 
synchronization at each moment in R is exactly the stop and 
wait strategy from [26], [27]. Since the run is given in the 
prefix- suffix form, our algorithmic framework will return a 
finite set of moments that require synchronization, as well as 
the type for each synchronization moment. 

IV. SOLUTION TO PROBLEM 3.2 

This section provides a solution to Problem 3.2. We first 
construct an algorithmic procedure for finding a set of neces- 
sary synchronization moments (Sec. IV-A - IV-C), and then 
we present a communication strategy guaranteeing that the 
synchronization moments are satisfied (Sec. IV-D). 

Without loss of generality, we assume that run R = 
R{1)R{2)R{3) . . . is in the prefix-suffix form (see Sec. II). 
Assume that the prefix has length k — I and the suffix has 

length /-y^+1, with 7?(7) = , for 7 = 1,...,/ 

(and 7?(/ + l) = R{k), 7?(/ + 2) =R{k^l), . . .). For avoiding 
supplementary notations implying repetitions of the suffix, we 
assume that whenever an index along R exceeds /, that index 
is automatically mapped to the set ...,/}, i.e. if j = I, 
then index j + 1 is replaced with k, and so on. For an easier 
understanding, we use superscripts for identifying a robot and 
subscripts for indexing the cells. 

For any robot / = 1 , . . . , ^ and for any moment j = 1 ,...,/ — 
1, cells c^j and c^-^^ are either adjacent or identical, and the 
same is true for cells c\ and c[. Recall that from the abstraction 
process of continuous robot trajectories, R does not contain 
any successive and finite repetition of a ^-tuple. 

A. Finding Synchronization Moments 

The idea of constructing a solution to Problem 3.2 is to start 
with no synchronization moments, and iteratively test if the 
formula can be violated and update the set of synchronization 
moments and their type. 

Let 5" C {1, ...,/} be an arbitrary set of synchronization 
moments, and let us impose the type of each synchronization 
moment by creating a map T : S ^ {weak ^strong}, where 
t(j) = weak means a weak synchronization at position j, and 
T{j) = Strong means a strong synchronization at position 7, 
Vj e S. 

As mentioned in Sec. III-C, a weak synchronization at 
moment j along run R means that the tuple R{j) is reached 



by the robots, i.e., there is a moment when the robots are in Algorithm 1 Solution to Problem 3.2 
cells cj, Cy, . . . ,c^, respectively. A strong synchronization 



at 

moment j along run R means that there is a weak synchro- 
nization at 7, and additionally the robots synchronously enter 
the next tuple (R{j-\-l)). In other words, all moving robots / 
cross from cells c^- to cells c^-^^ at the same time. 

One can observe that a strong synchronization at position j 
is not equivalent to two weak synchronizations at j and j + 1 . 
The strong synchronization guarantees that in the generated 
team run the tuple R{j) is immediately followed by the tuple 
R{j-\-l). However, the weak moments guarantee that the 
R{j) and R{j tuples are generated, but there may appear 
different tuples between them. It can be noted that a weak 
synchronization at moment j is equivalent with a strong one 
at the same moment if and only if j = k and the suffix of R 
has length 1 (k = I). 

For testing the correctness of a set of synchronization 
moments, we developed a procedure test_feasibility^{R^S^ t), 
which takes as inputs the formula (j), the run R, a set S of 
synchronization moments and a map T. The returned output is 
either "feasible" (set S with map T guarantees the satisfaction 
of the formula, no matter how the robots move in between 
synchronization moments) or "not feasible" (it is possible to 
violate the formula by imposing just the moments from S with 
type t). We postpone the details on test_feasibility(^ (7?, t) 
until Sec. IV-B. 

We use Algorithm 1 for obtaining a solution to Problem 
3.2, in the form of a set S of synchronization moments and 
a map T. The intuition behind this algorithm is to start with 
no synchronization moment {S = 0) and increase S until we 
obtain a feasible set together with a corresponding map T. We 
show the correctness of the solution given by Algorithm 1 in 
Sec. IV-C, together with more informal explanations on the 
provided pseudo-code. 

Remark 4.1 (Complexity): Algorithm 1 is guaranteed to 
finish, because in the worst case it returns the set 5" = { 1 , . . . , / }, 
meaning that strong synchronizations are needed at every 
moment (see Sec. IV-C). The worst case complexity requires 
3/(/ + 3)/2 iterations of the testj'easihility procedure. 

Remark 4.2 (Optimality): Algorithm 1 can be tailored 
such that it returns an optimal solution (with respect to a 
cost defined by weighting different synchronization moments). 
This can be done by first constructing all possible pairs 
5", T (there are 3^ such pairs). Then, these pairs should be 
ordered according to their associated cost. Finally, the pairs 
should be tested (in the found order) against the testj'easibility 
procedure, until a feasible response is obtained. Of course, the 
worst case would require 3^ iterations of testj'easibility (when 
the only solution is 5' = {1,...,/} and strong synchronization 
at every moment). 

B. Testing a Set of Synchronization Moments 

Procedure test_feasibility^{R^S^i:) follows several main 
steps: 

(i) It produces an automaton Ar^s.t generating all the infinite 
words (sequences of observed propositions) that can 



Inputs: Run R, formula (j) 
Outputs: Set S, map T 

1: for synchjype G {weak^ strong} do 

2: S = (d, T undefined 

3: lowerijound = 1^ moment = / 

4: while moment > lowerijound do 

5: if test_feasibility^{R^S,T) = "feasible" then 

6: Return set S and map T 

7: end if 



9: 
10: 
11: 
12: 

13: 
14: 
15: 
16: 
17: 
18: 
19: 
20: 
21: 
22: 
23: 



-'temp - 



■ S U {moment ^moment + 1, . . . ,/} 



= T{i),yieS 
^temp{i) = synchjype^ V/ G {moment + 1, . . . , /} 
for Ttemp{^oment) G {weak^ strong} do 

if test_feasibility^{R,Stemp^^temp) = "feasible" 

then 

S : = SU {moment} 
^{moment) = Ttemp{j^oment) 
lowerijoi^fid = moment 
moment = I 

Break "for" loop on Ttemp 
else 

moment := moment — 1 
end if 
end for 
end while 
end for 



result while the robots evolve and obey synchronization 
moments from S (this automaton has the form of a Btichi 
automaton with an observation map); 

(ii) If necessary, Ar^s.t is transformed into a standard (de- 
generalized) form; 

(iii) The product automaton between Ar^s,t and the Biichi cor- 
responding to negated LTL formula (^^^) is computed 
and its language is checked for emptiness; 

(iv) If the language is empty, the procedure returns "feasible" 
and otherwise it returns "not feasible". 

For step (i), the run R is projected to n individual runs, each 
corresponding to a specific robot. In each of these individual 
runs, we collapse the finite successive repetitions of identical 
states (cells) into a single occurrence (such repetitions mean 
that the individual robot stays inside a cell). Let us denote the 



resulted runs by R^ = q\ . 



. . ., where prefix has 



length ki — 1 {ki < k) and suffix has length U — ki^\ {U <l),i = 
1,...,^. Together with individual projections and collapsing, 
we construct a set of maps jS/ :{ 1 , 2, ...,/} ^ { 1 , 2, ...,/;•},/ = 
1 , . . . , ^, mapping each index from run R to the corresponding 
index from the individual run Rf (e.g. I5i{j) = j3;(7 + 1) if we 
have the same i^^ element in tuples R{j) and R{j-\-l)). 

Next, we obtain a generalized Biichi automaton Ar^s,t (see 
Def. 2.2) whose runs are the possible sequences of tuples of 
cells visited during the team evolution. Thus, the language 
of Ar^s.t contains all possible sequences of elements from 



2^ observed during the team movement. Each robot moves 
without synchronizing with the others, except for the moments 
from set S with type T. 

Definition 4.1: The automaton Ar^s,t is defined as Ar^s.t = 
(2A,^Ao,^A,^A,n,p), where: 

• Qa = {q\,q\,...,q\} X {q\,ql, . . . ,q^^^} X ... X 
{^15^2' • • • 5^?^} the set of states, 

• ^Ao = i^ijQv" ' j^i) is the initial state, 

• -^A ' Qa is the transition relation, 

• Fa C 2^^ is the set of sets of final states, 

• n is the observation set, 

• Pa ^ 2a ^ 2^ is the observation map, pA^qiAii- - • An) = 

u?=i{pte)}- 

The transition relation -^a is defined as follows: Mq^q' G 
Ga, with q = {q\,q\,...,ql) and q' = {q%q% . . . ,q'l), 
{q-,q') if and only if the following rules are simultane- 

ously satisfied: 

(a) ^ = if and only if ji = ki and ki = It, i= 1, . . . 

(b) q') e {q)A)^,} if j e {1,2, ...,/,• - 1}, and q') G {^,^1^ 
if j = li, /= 1,2,...,^; 

(c) if G 5" such that ji = lii{s) for / G / C {1, . . . ,^}, where 
/ is the largest possible subset of robots satisfying this 
requirement, then: 

(1) if / ^ {1, . . . ,^}, then q'). = q)., V/ G /; 

(2) if / = { 1 , . . . , ^} and t{s) = strong, then q^^j. = ^^.^^^^^ , 
V/ G /. 

Informally, requirements (a) and (b) capture a global 
progress/movement along individual runs of robots, by also 
capturing the possible situations when some robots advance 
"slower" (from the point of view that it takes more time for 
them to reach the next cell from partition). Requirement (c) 
restricts transitions by assuming that the agents satisfy all 
synchronization moments from S with type given by T. 

Before detailing the construction of Fa, we say that we 
consider as a generated word of Ar^s,t any trajectory that 
infinitely often visits all sets of states from Fa. This definition 
of generated words is exactly the definition of accepting 
words of generalized Biichi automata. Moreover, Ar^s,t has 
a structure similar to a Biichi automaton, which has final sets 
of states that are infinitely often encountered along an accepted 
run. 

The set of sets of final states of Ar s.t (Fa) is created 
by using Algorithm 2. The construction from Algorithm 2 
matches the purpose of generated runs of Ar^s.t^ in the sense 
that any run contains infinitely many revisits to tuples from 
suffix of R where synchronization is imposed. More details on 
the construction of Ar^s.t are given in Sec. IV-C. 

Once Ar^s.t is constructed, we have to check if there exists 
a generated word of Ar^s,t that violates the LTL formula (by 
satisfying the negation of the formula). As mentioned at the 
beginning of this section, this basically implies checking for 
emptiness the language of a product between Ar^s.t and 
(steps (ii)-(iv)). 

Similar to finding a run as mentioned in Sec. II, this 
emptiness checking can be done by using available software 



Algorithm 2 Set of final sets of automaton Ar^s.^^ 



Ssuffix = sn{k,...j} 

if ^,^,//^x = then 

^A = {<,..., ^/\}X {4,..., X...X{^^^,...,^^J 

else 

Assume Ssuffix = {^1 , ^2, • • • , } 

Fa = {FuF2,...,F\s^^^^.^\} 

for J = l,2,...,|^,^//,-;,| do 

end for 
end if 



tools for normal (degeneralized) Biichi automata. In case that 
Fa contains more than one set, Ar^s,t has the structure of a 
generalized Biichi automata. If this is the case, we first convert 
Ar^s,t into a degeneralized form (as mentioned in Sec. II), and 
then we construct the product with The construction of 

this product is similar to the one constructed between transition 
systems and Biichi automata [ ]. The only difference is that 
the set of final states of product equals the cartesian product 
between final states of (degeneralized) Ar^s,t and the final 
states of Biichi. 

Example of constructing Ar^s,t' We include here a simple 
example, solely for the purpose of understanding the construc- 
tion of Ar^s.T' Therefore, we do not define an environment, nor 
we impose an LTL formula. Consider a team of 2 robots and 
the following run R: 



R 



C5 
C6 



(4) 



R has a prefix of length 1, and a suffix of length 3 (the 
suffix is represented between square brackets). 

First, assume an empty set of synchronization moments, 
S = (b. By projecting R to individual runs and collapsing 
successive identical states, we obtain: R^ — q\ \q\q\q^^ and 

q\ [^hl] ' where q\ C5, q\ = cuq\ = cj, q\ C3, q\ 
C6, q2 = C2, ql = C4. The obtained automaton A/^ is given 
in Fig. 4(a), where the initial state is {q\^ql). This automaton 
is already in degeneralized form (it has a single set of final 
states), because S does not contain synchronization moments 
along suffix. Also, note that once the final set of A/^ is 
reached, it is never left. This corresponds to the fact that both 
robots reach and follow their suffixes (independently), and any 
possible observed sequence during the movement corresponds 
to a word generated by A/^ 0. 

Now, assume a set 5" = {2,4}, with t(2) = strong and 
t(4) = weak. This means there is a strong synchronization at 
the beginning of every iteration of suffix of R (state (ci,C2)) 
and a weak synchronization at the end (state (c3,C4)). The 
automaton Ar^s^t created as described in this subsection is 
given in Fig. 4(b). This automaton has the same set of states 
and observations as A/^ 0, but the set of transitions is reduced 
because of synchronization rules. Ar^s,t is in generalized form, 
because it has 2 sets of final states (Fi = (ql^ql) and F2 = 
(^47^3))- They gray states become unreachable because the 




(a) 



(b) 



Fig. 4. Examples of two automata constructed as described in Sec. IV-B, from 
run R from Eqn. (4): (a) © (b) A]^^^^2,a},t^ with t(2) = strong and t(4) = 
weak. Final states are double encircled, with different line types corresponding 
to different final sets, and the gray states are not reachable. 



reduced transitions of Ar^s^t- Note that any word generated by 
Ar^s,t infinitely often visits state {q\jql) (which corresponds 
to the first synchronization moment from S) and state {q\-,q\) 
(corresponding to the second synchronization moment from 
S). Also, there is only one outgoing transition from (^25^2)' 
in accordance with the strong synchronization in this state. 
It should be clear why in this case we have 2 sets of final 
states: if we had a single set, containing both (^25^2) 
(^4,^3), then Ar^s.t would have been accepting words like 
(^1.^1) [(^2'^2)(^3'd)(^4'^2)] •••• However, such a word 
would correspond to a spurious (impossible) movement of 
robots, because state {q\^q\) would never be visited, although 
it corresponds to a synchronization moment. ■ 

C. Correctness of Solution to Problem 3.2 

Theorem 4.1: Any solution returned by Algorithm 1 is a 
feasible solution to Problem 3.2, and Algorithm 1 returns a 
solution in a finite number of steps. 

Proof: The correctness of Algorithm 1 and of the 
"test_feasibility" procedure results by the construction we 
performed in this section, as detailed below. 

Correctness of "test_feasibility" procedure: We first 
prove that the "test_feasibility" procedure cannot yield a 
"feasible" output if the inputs S and T can produce a vio- 
lation of the formula. This comes from the requirements of 
the transition relation and from the construction of Fa. 
Requirement (a) from definition of ^a means that Ar^s,t does 
not self-loops, except for the case when all individual runs 
have suffixes of length 1 (in this case a self-loop exists for 
reiterating the suffix). Requirement (b) results from the fact 
that every robot / follows its individual run and iterates 
the suffix; the fact that there is no synchronization (a moving 
robot might not change its current cell, while others advance 
along their individual runs) is captured by the possibility of 
having qj = q'j for some robots. Thus, requirements (a) and 
(b) capture a global progress/movement along individual runs 
of robots, by enforcing iterations of individual suffixes. If we 
ignore requirement (c), and we assume that Fa is just a single 
set constructed as in line 3 of Algorithm 2, Ar^s.t can generate 
any possible run resulted while robots evolve without any 
synchronization (set S and map T were not yet used). Thus, 



if "test_feasibility" returns a "feasible" answer, it means that 
even the unsynchronized movement is feasible, so the motion 
restricted by (5", t) would definitely imply a satisfaction of 
0. However, such an approach would be very conservative, 
because it does not restrict the possible generated runs of Ar^s.t 
based on S and T^. 

Conservativeness reduction of Requirement (c) re- 
stricts transitions based on synchronization moments and their 
type. Thus, (c.(l)) guarantees that if one or more robots arrived 
at a synchronization moment, then they will not continue 
following the individual runs (by changing their states) unless 
all other robots arrived at that synchronization moment. This 
way, (c.(l)) captures the fact that the weak synchronization 
moments and the first part of the strong ones (visiting a certain 
tuple) are satisfied. Requirement (c.(2)) ensures that a tuple 
of cells corresponding to a strong synchronization moment 
is synchronously left by all robots that have to move at that 
index (the moving robots synchronously go to the next state 
from their individual run, while for other robots ^i{s ^ \) 
implies remaining in the same state/cell). The reduced set of 
transitions of Ar^s.t captures the satisfaction of all synchro- 
nization moments, and includes all possible unsynchronized 
(independent) movements of robots between synchronization 
moments. Therefore, the correctness of "test_feasibility" is not 
affected, while its conservativeness is reduced. 

Construction of Fa'* If there is no synchronization moment 
in the suffix of R, then Fa contains only one set, equal to the 
cartesian product of the sets of states composing the suffixes 
of individual runs /?^ / = 1, . . . ,^ (line 3 in Algorithm 2). This 
is because no synchronization moment in suffix of R means 
no synchronization moments in suffixes of individual runs. 
Therefore, the robots independently follow their suffixes and 
any n-tuple from set Fa can be infinitely often observed during 
the team evolution. In this case Ar^s.t is still too conservative, 
because it can generate many runs that cannot result from the 
actual movement of robots {e.g. infinite surveillance of just 
two states from Fa)- 

The set of accepted runs is drastically reduced if there 
are x synchronization moments in suffix of R (and also in 
individual suffixes). In this case. Fa will contain x sets (in 
Algorithm 2, x = \Ssuffix\)- Each of these sets contains just 
one tuple, which corresponds to one synchronization moment 
along individual suffixes. This construction comes from the 
following aspects: (i) due to synchronization moments along 
suffixes, we have additional information about some infinitely 
visited states, and considering Fa as in line 3 of Algorithm 2 
would be too conservative, (ii) If there are more synchroniza- 
tion moments along suffix, having a single set of final states 
that contains all the corresponding tuples would be again too 
conservative. This is because the transitions of Ar^s.t might 
allow infinitely often revisits to just a single element of that 
set, and we might get spurious counterexamples when testing 
Ar^s.t against the negation of LTL formula, (iii) In case of 

similar conservative approach was used in [ ], where only unsyn- 
chronized movements could be tested, and synchronization moments could 
not be handled. 



a strong synchronization moment j along the suffix, adding 
two states (tuples corresponding to R{j) and R{j -\- 1)) in the 
corresponding element of Fa would not bring any additional 
benefit than adding just R{j) (as done in Algorithm 2). This 
is because requirement (c.(2)) implies that the only possible 
transition from state corresponding to R{j) is to the state 
corresponding to R{j-\-l). Therefore, construction of Fa as 
in Algorithm 2 further reduces the conservativeness of Ar^s,t 
by restricting its set of generated runs with respect to S and T. 
'^R,s,T Still generates all possible sets of tuples that the team 
can follow while moments from S with type T are satisfied. 

There is one more step in proving the correctness of 
"test_feasibility", namely that there exists a pair S^T for 
which "test_feasibility" returns a "feasible" output. This pair 
is 5" = {1, . . . , /} and t(j) = strong, V7 G 5". Indeed, in this case 
every state of Ar^s,t has only one outgoing transition, and the 
only run generated by Ar^s.t is R- The word generated by R 
satisfies formula (j) (because R was constructed by assuming 
it is strongly synchronized at every position). Therefore, the 
language of the product between the degeneralized Ar^s.t and 
^^(j) is empty, and "test_feasibility" returns "feasible". 

Correctness of Algorithm 1: We now prove that Algorithm 
1 returns a feasible pair {S^t) in a finite number of steps. 
First, we explain Algorithm 1 and we show that the worst 
case (5" = {1, . . . ,/} and t{j) = strong, Wj e S) is returned, if 
no other less restrictive pair {S^ t) was encountered. 

Algorithm 1 starts with S = (d and T undefined, and increases 
S with at most one moment at every iteration of the "while" 
loop from line 4. For this, it goes from the last index in 
suffix of R (moment /) towards the first one, and it con- 
structs a temporary set of synchronization moments (Stemp)- 
Stemp includes all the moments from S (initially none) and 
all indices after the current moment until /. All moments 
following the currently tested one are first assumed to be 
weakly synchronized, and if no solution is obtained, they 
will be assumed strong (line 10 and "for" loop starting on 
line 1). This is because we consider a strong synchronization 
more disadvantageous than a weak one, due to the waiting 
and communication at borders separating adjacent cells. The 
current moment is first tested with a weak synchronization, 
and if no feasible answer results, it is tested with strong 
synchronization (loop starting on line 11). If the current test 
(with Stemp and Ttemp) is feasible, we add to set S only the 
current moment, with its current synchronization type stored 
in map T (lines 13, 14). Then, on line 15 we update the lower 
bound for the current synchronization moment (it doesn't make 
sense to go lower than the just found moment), and we start 
again the while loop on line 4 (from moment / towards the 
lower bound). For each disjoint assignment of "synchjype'" 
("for" loop on line 1), the currently tested moment inside the 
"while" loop from line 4 is build on the feasible moments 
existing in S and T until that instant (those moments are 
included in Stemp and Ttemp on lines 8, 9). 

Once a feasible pair Stemp j^temp is encountered, all future 
iterations from Algorithm 1) try to reduce the number of 
moments from Stemp and relax their synchronization type. In 



the worst case the same pair will be returned: if no other 
feasible pair included in this one is found, after a number 
of iterations of the "while" loop the same pair is again 
encountered (but this time, the first element of the old/feasible 
Stemp is already in S). Now, the second element from the old 
Stemp (the first from the new Stemp) is added to S and the 
"while" loop is again iterated, and so on. Thus, once a feasible 
pair is encountered. Algorithm 1 finishes in a finite number of 
steps. 

For proving that a feasible pair {Stemp i^temp) is ever en- 
countered, we show that, if no other feasible pair is found, the 
algorithm eventually tests the pair where Stemp = {l,---?^} 
and ttempU) = strong, V7 G Stemp (this pair is deemed feasible 
by the "test_feasibility" procedure, as shown before). When 
synch Jype = weak (first iteration of "for" loop on line 1), 
we iterate the "while" loop for / times and we do not get 
any feasible result. For synchjype = strong we would get 
Stemp = {1,...,/} and TtempU) = Strong, Vj G Stemp after 
another / iterations of the "while" loop. Even though we get 
a "feasible" answer from "test_feasibility", we add just the 
first moment from Stemp to 5" (so 5" = {1}) and reiterate. This 
time, at the (/ — 1)* iteration of the "while" loop we would 
get the same pair {Stemp ^^temp) (when moment = 2). Now, S 
is updated to 5" = {1,2} and the "while" loop is reiterated 
with lowerijound = 2. Since each iteration of "while" loop 
includes 3 calls to the "test_feasibility" procedure, the total 
number of such calls is: 3 (/ + / + (/ - 1) + (/ - 2) + . . . + 1) = 
3/(/ + 3)/2. 

By using a similar reasoning as above, it can be easily 
shown that if there exists a set 5" C {1, . . . ,/} and a map T 
for which test_feasibility^{R^S^T)='fQSisihlQ'\ then the pair 
{S^t) will be encountered by Algorithm 1 if other feasible 
pair is not encountered before. This shows why Algorithm 1 
does not necessarily find an optimal solution (with respect to a 
cost defined by weighting different synchronization moments): 
once a feasible pair {Stemp 1 '^temp) is encountered, all future 
iterations test only subsets of Stemp, not other sets from 
{1,. ..,/}. ■ 

D. Communication and Control Strategy 

We complete the solution to Problem 3.2 by providing a 
deployment strategy such that the synchronization moments 
from set S with type T are correctly implemented. A weak 
synchronization at moment j along R is achieved by enforcing 
each robot / to wait inside cell c^- (and signal this to others) 
until it receives a similar signal from all other robots. A 
strong synchronization at moment j is accomplished by first 
enforcing a weak synchronization at moment j, and then 
temporary stopping the robots for which ^ c^-^^ just before 
leaving cell c^j (and entering <^^+i). 

Since we need individual strategies, we have to adapt the set 
S and map T to descriptions suitable for each robot / that moves 
along its individual run / = 1, . . . To solve this, for each 
robot / we construct a queue memory Q\ where each entry 
contains the index along R^ when there should be enforced a 
synchronization, and the synchronization type. Alg. 3 creates 



these queue memories by adding l^"! entries, in the ascending 
order of moments from S. 



Algorithm 3 Queue memory 



1: 2^ = 

2: for all ^ G 5^ do 

3: Assume that S is sorted and states in S are enumerated 

sequentially 
4: moment = A(^) 
5: type = t{s) 

6: Add entry [moment^ type] at the end of 
7: end for 

The queues will be used by the robots in a FIFO manner, 
as in Alg. 4. Each robot follows the infinite run R\ by applying 
correct feedback controllers and by synchronizing with other 
robots when required. After fulfilling a synchronization mo- 
ment, the corresponding entry from is removed or moved to 
the end, depending on the inclusion of the current moment in 
prefix or suffix. The current index in is incremented based 
on specific conditions, for correctly handling the situations 
when two or more synchronization moments from S yield the 
same value through map Pi. Note that the robots not changing 
their cell when a strong synchronization moment is required 
still synchronize twice on that moment (for the weak and then 
the strong part), but they apply a convergence controller inside 
current cell. 

V. CASE STUDY REVISITED 

This section concludes the case study illustrated throughout 
the paper, by applying the procedure described in Sec. IV 
to the run from Eqn. (3). We obtain only two weak syn- 
chronization moments, at indices 8 and 12 of run R (first 
and fifth positions of every repetition of suffix). This makes 
sense, since the propositions satisfied by the team at the 
two synchronization moments are the two sets of regions 
({tTi^ 714^ 71^} and {712^ 71^}) that are required to be visited for 
the satisfaction of the formula. 

The individual runs of the robots are given in Eqn. (5), 
where the square brackets delimitate each suffix, and the two 
weak synchronization moments are marked in bold: 

R^ = Cj C2 Ci Cio C9 C18 C16 [C31] [C31] . . . 

7?^ = C4C3C6C8Ci7Cii [Ci2 Cn C17 Cg C6 Cg C17 Cn] . . . (5) 
R^ = C2g C25 C26 C24 [C38 <^24 C27 C20 C27 C24] • • • 

The control and communication protocol from Sec. IV-D 
points to the following deployment strategy for each robot: the 
robot moves along its individual run without any communica- 
tion, until it encounters a required synchronization moment. 
Then, it broadcasts that it is in a "ready" mode for the syn- 
chronization moment, and it waits inside the current cell until 
it receives "ready" signals for the current moment from all 
other robots. After this, each robot evolves again individually 
(without any synchronization) until the next synchronization 
moment. Note that for the above example, once robot 1 reaches 
its suffix it keeps applying a convergence controller inside C31 



Algorithm 4 Individual strategy for robot / 



9: 
10: 
11: 

12: 
13: 
14: 

15: 
16: 
17: 
18: 
19: 

20: 
21: 
22: 
23: 
24: 
25: 
26: 
27: 
28: 
29: 
30: 
31: 
32: 
33: 

34: 
35: 
36: 
37: 
38: 
39: 



7 = 1 

while TRUE do 

Read first entry [moment^ type] from 

Read second entry [next jnoment^ next _type] from 

if moment = j then 

while "ready" signals not received from all other 

robots do 

Broadcast a "ready to synchronize" signal 
Apply convergence controller inside current cell q^j 
from run R^ 
end while 

if next_moment ^ j then 

Apply controller driving to the next cell q^j^^ until 
border between q^j and q^j^^ is reached 

end if 

if type = strong then 

while "ready" signals not received from all other 
robots do 

Broadcast a "ready to synchronize" signal 
if next_moment ^ j then 

Stop robot 
else 

Apply convergence controller inside current 
cell q^j 
end if 
end while 
end if 

if j < ki then 

Remove first entry from Q 
else 

Move first entry from Q to the end of Q 
end if 

if nextjnoment 7^ j then 

7:= 7+1 

end if 
else 

if 7^ then 

Apply controller driving to the next cell q^j^^ until 
border between q^j and q^j^^ is reached 

else 

Apply convergence controller inside current cell q^j 
end if 
end if 
end while 



and broadcasting a "ready" signal (so that it does not induce 
waiting for other robots). 

Some snapshots from the deployment (implemented accord- 
ing to Sec. IV-D) are shown in Fig. 5, where two repetitions 
of the suffix for each robot are included. A movie for the case 
study is available at http://hyness.bu.edu/~software/unicycles. 
mp4. For comparison, if we avoided solving Problem 3.2 and 
instead used the deployment strategy from [ ], we would 
get the team trajectory illustrated by the movie http://hyness. 
bu.edu/~software/unicycles-full-synch.mp4. In this movie, we 
can see that the motions of the robots are not as "smooth" 
as our proposed approach, and the iterations for each suffix 
require more time. Our approach is more suitable for real 
experiments as robots have less frequent stops at region 
borders. 

Computation time: The most computationally intensive 
part of the solution to Problem 3.1 is finding a run R (as 
in Sec. III-A and III-B). For our case study, this took about 
100 minutes on a medium performance computer. In contrast, 
the solution we proposed for Prob. 3.2 (Sec. IV) took only 30 
seconds. To generate a solution for Prob. 3.2, 26 iterations of 
the testj'easihility procedure were performed until the set of 
synchronization moments was found. 

VI. ADDITIONAL EXAMPLE 

This section briefly presents another example on the same 
environment as in Fig. 1, but considering two robots and the 
LTL formula: 

= {^{n^ V ns)U{ni A n2)}^ 

{^{n^ V :/r4 V TZsWi^A A :^5)} A {On(7r3 V n^)} 

The curly brackets are only inserted to logically delimitate 
the requirements: (i) black and cyan regions (tts and TTs) should 
be avoided until red and green regions are visited, and (ii) 
black region is avoided until blue and cyan regions are entered 
at the same time, and (iii) eventually either the black or the 
magenta region should be visited and never left after that. 

By considering the robots initially deployed in regions c\ 
and C26 respectively, we obtained a run for the team with 12 
tuples in prefix and one in suffix. Informally, first robot goes to 
red region and the second one to the green one, then the robots 
move toward blue and cyan regions, and after these regions 
are simultaneously entered, the second robot goes to the black 
region and converge there, while the first robot remains in the 
blue region. 

By searching synchronization moments, we obtain only 
two such moments: a weak one, at the tuple when robots 
visit the red and green regions, and a strong one at the 
tuple before visiting the blue and cyan regions. The second 
synchronization moment guarantees that the blue and cyan 
regions are entered at the same time. These synchronization 
moments automatically found by our approach are natural at 
an insightful study of the requirement. The movement of the 
robots is depicted in the movie available at http://hyness.bu. 
edu/~software/unicycles-example2.mp4. In this movie one can 
observe both synchronization moments: (1) red robot arrives 



in the red region and it starts to converge there until the green 
robot visits the green region; (2) green robot arrives in cell 
C40 and starts to converge there until red robot visit cell C37 
(this is the weak synchronization part of the strong moment), 
and then the robots move towards blue and cyan regions. Red 
robot stops at the border between C37 and C29 and waits until 
the green robot reaches the border between C40 and C21 - this 
ensures the strong part of the synchronization (simultaneously 
change occupied cells). After this, no other communication 
between robots is required. 

VII. CONCLUSIONS 

We presented a fully automated framework for deploying a 
team of unicycles from a task specified as a linear temporal 
logic formula over some regions of interest. The approach con- 
sists of abstracting the motion capabilities of each robot into a 
finite state representation, using model checking tools to find 
a satisfying run, and mapping the solution to a communication 
and control strategy for each unicycle. The main contribution 
of the paper is the development of an algorithmic procedure 
that returns a reduced set of moments when the robots should 
communicate and synchronize, with the guarantee that the 
specification is satisfied. A secondary contribution is the inte- 
gration of this algorithm as part of a fully automatic procedure 
for deployment of teams of unicycles from specifications given 
as LTL formulas over regions of interest in an environment. 
Future research direction includes extending this framework 
to probabilistic systems such as Markov Decision Processes 
(MDPs) or Partially Observable Markov Decision Processes 
(POMDPs), for satisfaction of probabilistic temporal logics, 
such as probabilistic LTL or probabilistic CTL. 
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